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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Sretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access and Terminals (AT). 

The present document is part 3 of a multi-part deliverable supporting real-time multi media services, as identified 
below: 

Parti: "General"; 

Part 2: "Architectural framework for the delivery of time critical services over cable Television networks using 
cable modems"; 

Part 3: "Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable 
Television Networks using Cable Modems"; 

Part 4: "Network Call signalling Protocol"; 

Part 5: "Dynamic Quality of Service for the FYovision of Real Time Services over Cable Television Networks 
using Cable Modems"; 

Part 6: "Media Terminal Adapter (MTA) device provisioning"; 

Part 7: "Management Information Base (MIB) Framework"; 

Part 8: "Media Terminal Adapter (MTA) Management Information Base (MIB)"; 

Part 9: "Network Call Signalling (NCS) MIB Requirements"; 

Part 10: "Event Message Requirements for the Provision of Real Time Services over Cable Television Networks 
using Cable Modems"; 

Part 11: "Security"; 

Part 12: "Internet Signalling Transport Protocol"; 

Part 13: "Trunking Gateway Control Protocol"; 

Part 14: "Operation System Support". 

NOTE 1: The above list is complete for the first version of this Technical Specification (TS) (VI. 1.1 2001-06). 
Additional parts are being proposed and these will be added to the list in future versions. 

The present part is part 3 of the above mentioned series of ETSI deliverables and specifies the audio (voice) codecs that 
are to be used in the provisioning of bi-directional audio services over cable television distribution networks using IP 
technology (i.e. IPCablecom service). The present document also addresses codec options and packetization issues. 

NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future 
enhancements. 
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NOTE 3: The term MUST or MUST NOT is used as a convention in the present document part to denote an 
absolutely mandatory aspect of the specification. 



Introduction 

The cable industry in Europe and across other Global regions have already deployed broadband cable television Hybrid 
Fibre Coax (HFC) data networks running the Cable Modem Protocol. The Cable Industry is in the rapid stages of 
deploying IP Voice and other time critical multimedia services over these broadband cable television networks. 

The cable industry has recognized the urgent need to develop ETSI Technical Specifications aimed at developing 
interoperable interface specifications and mechanisms for the delivery of end to end advanced real time IP multimedia 
time critical services over bi-directional broadband cable networks. 

IPCablecom is a set of protocols and associated element functional requirements developed to deliver 
Quality-of-Service (QoS) enhanced sure IP multimedia time critical communications services using packetized data 
transmission technology to a consumer's home over the broadband cable television Hybrid Fibre/Coaxial (HFC) data 
network running the Cable Modem protocol. IPCablecom utilizes a network superstructure that overlays the two-way 
data-ready cable television network. While the initial service offerings in the IPCablecom product line are anticipated to 
be Packet Voice, the long-term project vision encompasses packet video and a large family of other packet-based 
services. 

The cable industry is a global market and therefore the ETSI standards are developed to align with standards either 
already developed or under development in other regions. The ETSI Specifications are consistent with the 
CableLabs/PacketCable set of specifications as published by the SCTE. An agreement has been established between 
ETSI and SCTE in the US to ensure, where appropriate, that the release of PacketCable and IPCablecom set of 
specifications are aligned and to avoid unnecessary duplication. The set of IPCablecom ETSI specifications also refers 
to ITU-SG9 draft and published recommendations relating to IP Cable Communication. 

The whole set of multi-part ETSI deliverables to which the present document belongs specify a Cable Communication 
Service for the delivery of IP Multimedia Time Critical Services over a HFC Broadband Cable Network to the 
consumers home cable telecom terminal. 'IPCablecom' also refers to the ETSI working group program that shall define 
and develop these ETSI deliverables. 

Many cable television operators are upgrading their facilities to provide two-way capability, and are using this 
capability to provide high-speed IP data services per ITU-T Recommendations J.83 and J.l 12. These operators now 
want to expand the capability of this delivery platform to include bi-directional voice communication and other time 
critical services. The present document is one of a series of documents required to achieve this goal. It provides 
guidance on audio (voice) codec selection that will provide for a high quality, interoperable service. 
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1 Scope 



The present set of documents specify IPCablecom, a set of protocols and associated element functional requirements. 
These have been developed to deliver Quality-of-Service (QoS), enhanced sure IP multimedia time critical 
communication services, using packetized data transmission technology to a consumer's home over a cable television 
Hybrid Fibre/Coaxial (HFC) data network. 

NOTE 1 : IPCablecom set of documents utilize a network superstructure that overlays the two-way data-ready cable 
television network, e.g. as specified within ES 201 488 and ES 200 800. 

While the initial service offerings in the IPCablecom product line are anticipated to be Packet Voice and Packet Video, 
the long-term project vision encompasses a large family of packet-based services. This may require in the future, not 
only careful maintenance control, but also an extension of the present set of documents. 

NOTE 2: The present set of documents aims for global acceptance and applicability. It is therefore developed in 
alignment with standards either already existing or under development in other regions and in 
International Telecommunications Union (ITU). 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, subsequent revisions do apply. 
ITU-T Recommendation G.165 (1993): "Echo cancellers". 

ITU-T Recommendation G.168 (1997): "Digital network echo cancellers". 

ITU-T Recommendation G.711 (1988): "Pulse code modulation (PCM) of voice frequencies". 

ITU-T Recommendation G.728 (1992): "Coding of speech at 16 kbit/s using low-delay code excited linear prediction". 

ITU-T Recommendation G.729 (1998): "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited 
linear-prediction (CS-ACELP); Annex E: 1 1.8 kbit/s CS-ACELP speech coding algorithm". 

ITU-T Recommendation J. 83 (1997): "Digital multi-programme systems for television, sound and data services for 
cable distribution". 

ITU-T Recommendation J. 11 2: "Transmission systems for interactive cable television services". 

ITU-T Recommendation V.18 (1998): "Operational and interworking requirements for DCEs operating in the text 
telephone mode". 

RFC 1890 (1996): "RTP Profile for Audio and Video Conferences with Minimal Control". 

RFC 2327 (1998): "SDP: Session Descripdon Protocol". 

ETSI ES 201 488: "Data-Over-Cable Service Interface Specifications; Radio Frequency Interface Specification". 

ETSI ES 200 800: "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems 
(CATV)". 

ITU-T Recommendation G.726: "40, 32, 24, 16 kbit/s adaptive differential pulse code modulation (ADPCM)". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Node: layer two termination device that terminates the network end of the ITU-T Recommendation J. 1 12 
connection 

NOTE: It is technology specific. In ITU-T Recommendation J.l 12 annex A it is called the INA while in annex B 
it is the CMTS. 

Cable Modem: layer two termination device that terminates the customer end of the J. 1 12 connection 

IPCablecom: ETSI working group project that includes an architecture and a series of Specifications that enable the 
delivery of real time services (such as telephony) over the cable television networks using cable modems 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AN Access Node 

CPE Customer Premise Equipment 

DTMF Dual Tone Multi Frequency 

HFC Hybrid Fibre Coax 

IP Internet Protocol 

MTA Media Terminal Adaptor 

PSTN Public Switched Telephone Network 

QoS Quality-of-Service 

VAD Voice Activity Detection 



Audio Codec Requirements 



Offering a competitive and/or superior product requires support for more than high-quality delivery of audio. In 
addition to features and signalling capabilities, which are beyond the scope of this document, the audio codec 
application must provide transparent support for certain audio features. These include general detection mechanisms, 
DTMF, fax, analog modem, echo cancellation, and hearing-impaired support. 



4.1 DTMF support 



Dual-tone multi-frequency (DTMF) support allows employment of dual-tone multiple frequency signals by either an 
autodialing system or through manual entry of tones. In order for DTMF tones to be captured correctly by the receiving 
device, tonal integrity (frequency accuracy and signal duration) must be maintained even through compression and 
transcoding. 

MTA devices must successfully pass DTMF tone transmissions. The specified codecs must be capable of transparently 
passing these tones in-band. 



4.2 Fax and Modem Support 



IPCablecom needs to support analog fax and modem interfaces for two reasons. First, fax and modem equipment are 
common, and customers will continue to use these familiar devices for some years to come. Sond, even with cable 
modem access, many users will continue to access their dial-up networks using a traditional modem. 
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In order to provide customers with access for analog fax and modems, Media Terminal Adapter (MTA) devices must be 
able to detect fax/modem signals and signal these detections using the appropriate protocol. The codec at each end is 
then switched to G.711 for the remainder of the session. Additionally, echo cancellation is disabled for the duration of 
the fax/modem session. After the fax/modem session has completed, echo cancellation is re-enabled. 

A more robust solution for supporting fax is to employ fax relay. Fax relay involves demodulating the T.30 
transmission and sending control and image data over the IP network. At the receiving end, the received data is 
remodulated and sent to the fax terminal using another T.30 session. This is described in the ITU-T standard T.38. 
Client devices may employ fax relay. 



4.3 Echo Cancellation Support 



When end-to-end delay in an audio communication is more than 20 ms, an artifact called line echo can occur. This 
echo, if not removed, will be heard by the remote talker (thus it is also called talker echo) whenever he or she speaks. 

Line echo cancellation must be provided in IPCablecom MTA and Gateway devices to mitigate the effects of line echo. 
This echo canceller must allow both parties to speak simultaneously (double-talk), so that one talker does not seize the 
line and block out the other user from being heard. 

During periods when only the remote talker is speaking, the local echo canceller should either inject comfort noise or 
allow some noise to pass through to the remote talker, so that a "dead-line" is not perceived. However, if local voice 
activity detection (VAD) is enabled, either the noise injection should be disabled, or the echo canceller should 
communicate its state with the VAD, in order for the VAD to not estimate the injected noise mistakenly as the true 
background noise. 

In an application where the MTA is located in a home, the length of the echo canceller is typically short (8 ms or less). 
For PSTN gateway applications, the echo canceller length is typically much longer (32 ms or longer). Vendors may 
choose to differentiate their products by providing longer echo canceller lengths suitable for their application, or other 
programmable parameters. 

In applications where a non-standard bi-directional audio interface is used (e.g., microphone and headset), echo 
cancellation may not be necessary. However, where a microphone and speakers are used, acoustic echo cancellation 
may be necessary, and vendors implementing these products should employ acoustic echo cancellation. 

The performance of the line echo canceller should comply with either ITU-T Recommendation G.165 or ITU-T 
Recommendation G.168. 

4.4 Asymmetrical Services Support 

MTA devices should be capable of supporting employment of different codecs for upstream and downstream audio 
channels. This allows potential optimization of device resources, network bandwidth, and user service quality. 

4.5 Hearing-impaired Services Support 

For hearing-impaired people, TDD equipment can be the primary communication link to the outside world. This type of 
equipment has evolved lacking the type of standardization allowing broad interoperability among international 
manufacturers. The ITU recently adopted the V.18 standard to begin alleviating this problem. ITU-T Recommendation 
V.18 outlines a procedure, which includes protocol negotiation for connecting these devices. 

Since CPE for the hearing impaired consists of text input/output devices coupled with voice-band modems, any system 
designed to support them would need to be able to pass voice-band modem tones coherently. Of the list of proposed 
voice codecs, only G.71 1 would be able to achieve this, given that the other standards are not designed for passage of 
complex tones associated with modem communications. Typically, these devices will interface to the PSTN via an 
acoustical coupler to a phone or with a regular telephone jack. 

MTA devices must support detection of ITU-T Recommendation V.18 hearing-impaired tones, including V.18 
annexes A, B and F. Support for ITU-T Recommendation V.18 annex G is optional. Upon detection of a V.18 signal, 
the codec at each end is then switched to G.71 1 for the remainder of the session. Additionally, echo cancellation is 
disabled for the duration of the V.18 call. It is optional to disable echo cancellation for annex B because it is 
DTMF-based. After the session has completed, echo cancellation is re-enabled. 
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Mandatory Codecs 



G.71 1 must be supported in all MTAs. This codec provides high-quality service and is ubiquitous. It provides the 
"fallback" position for services such as fax, modem, and hearing-impaired services support, as well as common gateway 
transcoding support. In addition, G.71 1 is used as the fallback mode if there are not enough resources to establish a new 
connection using the requested codec (e.g. two channels of G.728 or G.729 annex E are already in existence, and there 
are not enough resources for a third connection to use a compressed codec). 



5.1 |i-law and A-law Support 



Both G.711 encoding modes (|i-law and A-law) must be supported. If the analog-to-digital interface at the encoder uses 
A-law encoding, then A-law encoding must be selected for G.71 1 encoding. Otherwise, if the analog-to-digital interface 
at the encoder uses |i-law encoding, then |i-law encoding must be selected for G.711 encoding. 

However, if one end of a voice connection uses an A-law interface, while the other end uses p-law, then the A-law 
decoder MUST transcode the incoming |i-law packets to A-law, while the p-law decoder MUST transcode the 
incoming A-law packets to |i-law. 

5.2 Packet Loss Concealment 

All Media Gateways and Multimedia Terminal Adaptors MUST detect audio packet loss and implement some method 
to conceal losses from end-users. Specifications for low bit rate codecs (e.g. G.728 and G.729) include methods for 
concealment. For G.71 1 implementations, the method defined in G.71 1 Appendix I is recommended. 

6 Additional Codecs 

In addition to G.71 1, MTAs also should support at least one of the following codecs. 

6.1 G.728 

G.728 should be supported in all MTAs. IPCablecom has a need to provide best or high voice quality. G.728 is a 
mid-bitrate (16 kb/s), high-quality solution. Supporting a codec in this range provides high-quality, low-bandwidth 
performance for on-net calls and ensures the highest possible performance for applications, such as IVR systems. In 
addition, it provides superior background noise handling. 

6.2 G.729 annex E 

G.729 annex E should be supported in all MTAs. IPCablecom has a need to provide best or high voice quality. G.729 
annex E is a mid-bitrate (1 1,8 kb/s), high-quality solution. Supporting a codec in this range provides high-quality, 
low-bandwidth performance for on-net calls and ensures the highest possible performance for applications, such as IVR 
systems. In addition, it provides superior background noise handling. 



7 Optional Features 

7.1 Wideband Codecs 

Given that the majority of early customers will be "black phone" users, support for a wideband (i.e. greater than circuit 
voice bandwidth) codecs is not necessary. However, some vendors optionally may choose to differentiate their product 
by selecting components that will support higher fidelity in the event a wideband codec is provisioned at some time in 
the future. 
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7.2 Optional Codecs 

A vendor may supply any codecs not described herein. 

7.3 Voice Activity Detection (VAD) 

A vendor may employ VAD to reduce bandwidth consumption. If employed, this capability must be optional, allowing 
disabling. 

8 Packetization 

Packet size influences both delay and the impact of packet loss. The larger the packet size, the greater the delay and the 
greater the impact of a lost packet. This suggests that the optimal packet size for voice applications is fairly small. 
Individual packets should not contain more than 20 ms of voice frames and must not contain more than 30 ms of voice 
frames. In addition, individual packets must contain an integral number of frames of sampling data, and any one frame 
of sampling data must be totally contained within one packet. 
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Annex A (normative): 

Session Description of CODECs 



Session descriptor protocol (SDP) messages are used to describe multimedia sessions for the purposes of session 
announcement, session invitation, and other forms of multimedia session initiation. SDP descriptions are used in both 
Network Call Signalling (NCS) [J.ncs] and Distributed Call Signalling (DCS) [future]. This clause describes the 
required specification of the codec in SDP, and the required mapping of the SDP description into RSVP flowspecs. 

A typical SDP description contains many fields that contain information regarding the session description (protocol 
version, session name, session attribute lines, etc.), the time description (time the session is active, etc.), and media 
description (media name and transport, media title, connection information, media attribute lines, etc.). The two critical 
components for specifying a codec in an SDP description are the media name and transport address (m) and the media 
attribute lines (a). 

The media name and transport address (m) are of the form; 

m=<media> <port> <transport> <fmt list>. 
The media attribute line(s) (a) are of the form: 

a=<token>:<value>. 
A typical IP-delivered voice communication would be of the form: 

- m=audio 3456 RTP/AVP 0; 

a=ptime:10. 

On the transport address line (m), the first term defines the media type, which in the case of an IP voice 
communications session is audio. The sond term defines the UDP port to which the media is sent (port 3456). The third 
term indicates that this stream is an RTP Audio/Video profile. Finally, the last term is the media payload type as defined 
in the RTP Audio/Video Profile (reference RFC 1890). In this case, the represents a static payload type of u-law PCM 
coded single channel audio sampled at 8 kHz (A value of 8 would be used to represent A law). On the media attribute 
line (a), the first term defines the packet formation time (10 ms). 

Payload types other than those defined in RFC 1890 are dynamically bound by using a dynamic payload type from the 
range 96 - 127, as defined in RFC 2327, and a media attribute line. For example, a typical SDP message for G.726 
would be composed as follows: 

- m=audio 3456 RTP/AVP 96; 

- a= rtpmap:96 G726-32/8000. 

The payload type 96 indicates that the payload type is locally defined for the duration of this session, and the following 
line indicates that payload type 96 is bound to the encoding "G726-32" with a clock rate of 8 000 samples/s. 

CODECs defined in this specification MUST be encoded with the following string names in the rtpmap parameter: 

Table A.I : Codec RTPMap Parameters 



Codec 


Rtpmap Parameter 


G.726at16kb/s 


G726-1 6/8000 


G.726at24kb/s 


G726-24/8000 


G.726at32kb/s 


G726-32/8000 


G.726at40kb/s 


G726-40/8000 


G.728 


G728/8000 


G.729A 


G729A/8000 


G.729E 


G729E/8000 



In addition, G.71 1 MAY be encoded with a dynamic payload type code, in an rtpmap parameter using the name 
PCMU/8000. 
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For every defined CODEC (whether it is represented in SDP as a static or dynamic payload type), table A.2 describes 
the mapping that MUST be used from either the payload type or ASCII string representation to the bandwidth 
requirements for that CODEC. 

The Mapping of RTP/AVP code to RSVP Flowspec (as used by Dynamic Quality of Service [J.dqos])) must be 
according to table A.2. The implementation of the 15 ms time period for G.71 1 CODEC is mandatory. All other 
implementations are optional. 

Table A.2: Mapping of Session Description Parameters to RSVP Fiowspec 



Parameters from Session Description 


Flowspec parameters 


Comments 


RTP/AVP 
code 


Rtpmap 


Ptime 
(ms) 


Values b, 

m, M 
(note 1) 


Values r, p 
(note 2) 





<none> 


9 


1 1 2 bytes 


1 2 444 bytes/s 


G.711 using the 
Payload Type 
defined by IETF 





<none> 


10 


1 20 bytes 


1 2,000 bytes/s 





<none> 


15 


1 60 bytes 


1 666 bytes/s 





<none> 


20 


200 bytes 


1 0,000 bytes/s 





<none> 


30 


280 bytes 


9,333 bytes/s 


96-127 


PCMU/8000 


9 


1 1 2 bytes 


1 2 444 bytes/s 


G.711 PCM, 64 
kb/s, default 
CODEC 


96-127 


PCMU/8000 


10 


1 20 bytes 


1 2,000 bytes/s 


96-127 


PCMU/8000 


15 


1 60 bytes 


1 666 bytes/s 


96-127 


PCMU/8000 


20 


200 bytes 


10,000 bytes/s 


96-127 


PCMU/8000 


30 


280 bytes 


9,333 bytes/s 


96-127 


G726-1 6/8000 


10 


60 bytes 


6,000 bytes/s 




96-127 


G726-1 6/8000 


20 


80 bytes 


4,000 bytes/s 


96-127 


G726-1 6/8000 


30 


1 00 bytes 


3,333 bytes/s 


96-127 


G726-24/8000 


10 


70 bytes 


7,000 bytes/s 




96-127 


G726-24/8000 


20 


1 00 bytes 


5,000 bytes/s 


96-127 


G726-24/8000 


30 


1 30 bytes 


4,333 bytes/s 


2 


<none> 


10 


80 bytes 


8,000 bytes/s 


G. 726-32, identical 
to G. 721, which is 
assigned Payload 
Type 2 by IETF 


2 


<none> 


20 


1 20 bytes 


6,000 bytes/s 


2 


<none> 


30 


1 60 bytes 


5,333 bytes/s 


96-127 


G726-32/8000 


10 


80 bytes 


8,000 bytes/s 




96-127 


G726-32/8000 


20 


1 20 bytes 


6,000 bytes/s 


96-127 


G726-32/8000 


30 


1 60 bytes 


5,333 bytes/s 


96-127 


G726-40/8000 


10 


90 bytes 


9,000 bytes/s 




96-127 


G726-40/8000 


20 


1 40 bytes 


7,000 bytes/s 


96-127 


G726-40/8000 


30 


1 90 bytes 


6,333 bytes/s 


15 


<none> 


10 


60 bytes 


6,000 bytes/s 


G.728, assigned 
Payload Type 1 5 
by IETF 


15 


<none> 


15 


70 bytes 


4 666 bytes/s 


15 


<none> 


20 


80 bytes 


4,000 bytes/s 


15 


<none> 


30 


1 00 bytes 


3,333 bytes/s 


96-127 


G728/8000 


10 


60 bytes 


6,000 bytes/s 


G.728, LD-CELP, 
1 6 kb/s 


96-127 


G728/8000 


15 


70 bytes 


4 666 bytes/s 


96-127 


G728/8000 


20 


80 bytes 


4,000 bytes/s 


96-127 


G728/8000 


30 


1 00 bytes 


3,333 bytes/s 


18 


<none> 


10 


50 bytes 


5,000 bytes/s 


G.729A, identical to 
G.729, assigned 
Payload Type 1 8 
by IETF 


18 


<none> 


20 


60 bytes 


3,000 bytes/s 


18 


<none> 


30 


70 bytes 


2,333 bytes/s 


96-127 


G729A/8000 


10 


50 bytes 


5,000 bytes/s 


G.729A, 

CS-ACELP, 8 kb/s, 
10 ms frame size 
with 5 ms 
lookahead 


96-127 


G729A/8000 


20 


60 bytes 


3,000 bytes/s 


96-127 


G729A/8000 


30 


70 bytes 


2,333 bytes/s 
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Parameters from Session Description 


Flowspec parameters 


Comments 


RTP/AVP 
code 


Rtpmap 


Ptime 
(ms) 


Values b, 

m, M 
(note 1) 


Values r, p 
(note 2) 


96-127 


G729E/8000 


10 


55 bytes 


5,500 bytes/s 


G.729E, 
GS-AGELP, 
1 1 ,8 kb/s, 1 ms 
frame size witli 
5 ms lookaliead 


96-127 


G729E/8000 


20 


70 bytes 


3,500 bytes/s 


96-127 


G729E/8000 


30 


85 bytes 


2,833 bytes/s 


N0TE1: b: is bucket depth (bytes). 

m: is minimum policed unit (bytes). 

M: is maximum datagram size (bytes). 
NOTE 2: r: is bucket rate (bytes/s). 

p: is peak rate (bytes/s). 
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